Подскажите как определить является ли node ссылкой

[nds]

Подскажите как определить является ли node ссылкой и как вытащить из нее url.

[ZoNT]

if (/^a$/i.test(element.tagName)) alert('Является ссылкой, и вот её url: '+element.href);

[nds]

Спасибо

[SelenIT]

А почему бы сразу не проверять наличие свойства href (тегов link и base в document.body быть не должно, а a и area — и есть ссылки)?

[s0rr0w]

if (/^a$/i.test(element.tagName)) alert('Является ссылкой, и вот её url: '+element.href);

Зачем тормозной регексп? Вдобавок, читать данный код просто нереально.

Почему не использовать просто if ( element.nodeName == "A") ... ?

Читается на порядок лучше, работает в 2 раза быстрее.

[ZoNT]

Затем, что это перестарховка на случай хренового браузера, которы выдаст "а" в нижнем регистре.

Предупреждение возможных ошибок лучше, чем поиск багов потом... Если требуется производительность - тогда да. Надо отрубить альтернативные браузеры на уровне сервера и выдавать контент только тем кто работает быстро (например ие6 тоже отрубить, ведь он "тормозной").

Мы сечас не спорим про скорость выполнения функции, а разбираем пример.

Я считаю лучше дать новичку такой ответ, который будет работать при любых обстоятельствах. Ведь если бы ты ему дал свой ответ, думаешь он бы догадался потом писать названия тегов в ерхнем регистре? Это были бы потенциальные грабли...

А так пусть лучше люди приходят с вопросм "Как увеличить производительность?", чем "где ошибка?"...

[s0rr0w]

Затем, что это перестарховка на случай хренового браузера, которы выдаст "а" в нижнем регистре.

У вас есть пример такого браузера?

Предупреждение возможных ошибок лучше, чем поиск багов потом...

Тогда не забудьте проверить на наличие элемента и наличие свойства tagName у этого элемента. А также, есть ли regExp у данного браузера.

Я считаю лучше дать новичку такой ответ, который будет работать при любых обстоятельствах.

Особенно полезно давать непонятный пример, когда пользователь не с первого раза разберется в том, как это все работает. Вы делаете медвежью услугу, даете готовое решение, но не даете ясности в понимании кода.

Ведь если бы ты ему дал свой ответ, думаешь он бы догадался потом писать названия тегов в ерхнем регистре? Это были бы потенциальные грабли...

Человек задал бы вопрос еще раз, что у него не сработал скрипт, ему бы дали пояснение, что в HTML все имена тегов идут в верхнем регистре. Он бы запомнил это раз и на всегда. Это плохо?

[Great Rash]

Затем, что это перестарховка на случай хренового браузера, которы выдаст "а" в нижнем регистре.

Можно написать так:

if (element.nodeName.toUpperCase() == "A")

[SelenIT]

У вас есть пример такого браузера?

FF1±, Opera 8+, Safari 1+, Chrome... если страница отдана с XHTML-ным Content-type

P.S. Не каждый элемент A — ссылка (знаю, знаю, <a name="..."> маст дай... но тем не менее). И не каждая ссылка, имхо — A (как насчет <area href="...">?)...

Edited May 7, 2009 by SelenIT

[s0rr0w]

FF1±, Opera 8+, Safari 1+, Chrome... если страница отдана с XHTML-ным Content-type

P.S. Не каждый элемент A — ссылка (знаю, знаю, <a name="..."> маст дай... но тем не менее). И не каждая ссылка, имхо — A (как насчет <area href="...">?)...

hhttp://www.w3.org/TR/xhtml1/#C_11

1. User agents that access XHTML documents served as Internet media type text/html via the DOM can use the HTML DOM, and can rely upon element and attribute names being returned in upper-case from those interfaces.

2. User agents that access XHTML documents served as Internet media types text/xml, application/xml, or application/xhtml+xml can also use the XML DOM. Elements and attributes will be returned in lower-case. Also, some XHTML elements may or may not appear in the object tree because they are optional in the content model (e.g. the tbody element within table). This occurs because in HTML 4 some elements were permitted to be minimized such that their start and end tags are both omitted (an SGML feature). This is not possible in XML. Rather than require document authors to insert extraneous elements, XHTML has made the elements optional. User agents need to adapt to this accordingly. For further information on this topic, see [DOM2]

Автор топика не уточнял, что именно он использует, но, скорее всего, HTML, или на крайний случай XHTML с media type text/html (потому что другого тупой ИЕ не понимает)

[Riim]

Тупанул. Как удалить все сообщение не нашел.

Edited May 8, 2009 by Riim

[e1f]

А почему tagName? здесь, например, написано насчет него Don't use:

nodeName contains all functionalities of tagName, plus a few more. Therefore nodeName is always the better choice.

Это к посту Riim, он его успел удалить

Не nodeName, а tagName. При этом у текстовых узлов (которые могут попадать в выборку) tagName равен undefined. При вызове метода (toUpperCase) на undefined или null происходит ошибка.

Лучше так:

if ((element.tagName || '').toLowerCase() == 'a')

Edited May 8, 2009 by e1f

[nds]

Спасибо всем за развернутый ответ.

P.S. Тип документа может быть любой так как этот код будет использоваться в user JavaScript-е оперы

[Riim]

nodeName contains all functionalities of tagName, plus a few more. Therefore nodeName is always the better choice.

Спасибо. Буду знать. Просто я как всегда поспешил ответить, не разобравшись до конца.

[Great Rash]

nodeName contains all functionalities of tagName, plus a few more.

А это какая функциональность еще у nodeName присутствует?

[s0rr0w]

А почему tagName? здесь, например, написано насчет него Don't use:

Это к посту Riim, он его успел удалить

Вообще странно читать такой бред на вполне адекватном, как казалось раньше, сайте.

Есть два разных интерфейса - Node и Element. Нода - это базис любого документа. Element - это частный случай ноды, и это теги.

Так как элемент наследует все свойства ноды, то для него нет разницы, что использовать, или nodeName, или tagName. Результат будет одинаковый. Свойство tagName не является запрещенным.

Честно говоря, я удивлен столь странным выводам, что tagName лучше не использовать.

[Nekromancer]

Извините меня пожалуйста

Вопрос был как узнать является ли Ноде ссылкой? так?

ну так почему бы не проверять у него наличие атрибута href? И если он найден просто возвращать его значение.

На крайний случай можно проверить и src и data..

Edited May 9, 2009 by Nekromancer

[Nekromancer]

я точно не знаю, но по идее так:

if(document.getElementById('Test').href){
return document.getElementById('Test').getAttribute('href');
}else{
return 'Это не есть ссылка!';
}

По идее так, а место "getElementById('Test')" ваше условие как вы будите искать этот самый Ноде..

[s0rr0w]

ну так почему бы не проверять у него наличие атрибута href? И если он найден просто возвращать его значение.

Потому что LINK тоже имеет параметр href, но не является ссылкой.

Атрибут можно установить любой ноде, но эта нода не будет являться ссылкой.

[Nekromancer]

Потому что LINK тоже имеет параметр href, но не является ссылкой.

а если проверять ноды только в боди?

Атрибут можно установить любой ноде, но эта нода не будет являться ссылкой.

Ожидал такой ответ. А кому это надо скажи, это просто лишняя причина. Зачем извращаться над самим собой? %)

[s0rr0w]

Ожидал такой ответ. А кому это надо скажи, это просто лишняя причина. Зачем извращаться над самим собой? %)

Лучше смотреть немного вперед.

Когда мы будем проверять только на совпадение "A", то у нас есть только одно слабое место - XML и синтаксис с нижним регистром. Это достаточно легко исправляется добавлением апперкейза.

А вот если мы будем проверять на наличие свойства href, то это может привести к потенциальному багу в будущем. Баг заключается в том, что если попадется другой плагин, который будет использовать href для внутренней работы, то два плагина будут мешать друг другу.

Судя по поставленной задаче, скрипт не знает, что за ноду ему подсунули, и поэтому лучше не рисковать.

[Nekromancer]

эм.. ну не знаю

Наверно, все решает конкретный случий.

[s0rr0w]

эм.. ну не знаю

Наверно, все решает конкретный случий.

99% программеров делают код под конкретный случай, не задумываясь над тем, что будет с этим кодом завтра.

[SelenIT]

Когда мы будем проверять только на совпадение "A", то у нас есть только одно слабое место - XML и синтаксис с нижним регистром. Это достаточно легко исправляется добавлением апперкейза.

А вот если мы будем проверять на наличие свойства href, то это может привести к потенциальному багу в будущем. Баг заключается в том, что если попадется другой плагин, который будет использовать href для внутренней работы, то два плагина будут мешать друг другу.

Что-то моей фантазии не хватает, как считывание свойства href одним плагином может помешать другому. Если же плагин "для своей внутренней работы" развешивает левым элементам кастомные свойства, совпадающие по имени со стандартными DOM-свойствами других элементов... то, имхо, это просто хреновый плагин, который надо срочно фиксить (а лучше сразу выбросить .

А вот <a name="...">, к сожалению, еще встречается (не далее как позавчера, кажись, его даже советовали на этом форуме), так что предположение, что все <a> суть ссылки, ломается уже здесь. И как все-таки быть со ссылками на мэпах (<area href="...">)?

[s0rr0w]

Что-то моей фантазии не хватает, как считывание свойства href одним плагином может помешать другому. Если же плагин "для своей внутренней работы" развешивает левым элементам кастомные свойства, совпадающие по имени со стандартными DOM-свойствами других элементов... то, имхо, это просто хреновый плагин, который надо срочно фиксить (а лучше сразу выбросить .

Я бы предложил вам сменить мышление. Ваше - негибкое.

Подумайте сами, зачем вы себя ограничиваете какими-то надуманными рамками, навешиваете условности, создаете и подчиняетесь каким-то правилам, которые сужают ваше мышление?

Есть задачи, в которых создание кастомных свойств у тегов решает 90% всех проблем. Приведу пример тот же StateController. Да, я добавил невалидное свойство, но я таким образом решил множество проблем. Сейчас, после двух лет применения SC я понимаю, что я не ошибся в технологии. 95% кода - унифицированные запросы и команды. Читать легко, понимать код - легко, изменять - проще простого. Если бы я использовал jQuery, то я погиб бы под тоннами кода.

Да, я пошел против принципов, которые навязываются отовсюду, что разделять html и js - признах хорошего тона. Да бред это все! Все зависит от уровня абстракции, с которым оперирует программист. Я принял html-код не за константу, а за базис всех процессов, которые происходят с контентом. Структура управляет процессами, а не процессы управляют структурой. Все мыслят категориями "ID, className, nodeName" и их производными, а я мыслю категориями "родитель с заданным именем ноды, родитель с заданным именем класса, childNodes, дерево элементов", в добавок к всем первым вариантам. Я работаю с деревом HTML, а не с плоскими массивами нод. Если бы я себя ограничивал, то никогда бы не написал SC. Потому что понять соль технологии можно только тогда, когда вы измените свое мышление.

Я вам приведу живой пример того, как выход за рамки обычного мышления, порождает успешное решение. Lightbox и активация плагина через совершенно необычное свойство rel, которое предназначено совершенно для других целей. Вы сразу броситесь выбразывать этот плагин, потому что он, подлец, подменяет понятия?

[SelenIT]

SC — исключение из правил . Против кастомных свойств и атрибутов я ничего не имею (тем более перспективный стандарт позволяет вполне свободно применять их, не теряя валидности , я против намеренной путаницы: зачем называть кастомное свойство href, когда можно myhref, mysuperpseudohref и т.д. — во-первых, доставать легче (свои не путаются со встроенными), во-вторых, зачем ограничивать собственную фантазию?

я мыслю категориями "родитель с заданным именем ноды, родитель с заданным именем класса, childNodes, дерево элементов"

Хм... был уверен, что пресловутый JQuery именно на такой подход и ориентирован (не говоря о YASS и т.п. развитях темы). Впрочем, сам пользуюсь фреймворками редко (один-два простых эффекта мне проще руками написать), так что судить не берусь

Lightbox и активация плагина через совершенно необычное свойство rel, которое предназначено совершенно для других целей.

For a and area elements that represent hyperlinks, the relationship between the document containing the hyperlink and the destination resource indicated by the hyperlink is given by the value of the element's rel attribute, which must be a set of space-separated tokens. The allowed values and their meanings are defined below. The rel attribute has no default value. If the attribute is omitted or if none of the values in the attribute are recognized by the user agent, then the document has no particular relationship with the destination resource other than there being a hyperlink between the two.

Согласен, нестандартное значение свойства rel для привязки плагина — "рак на безрыбье", вынужденная мера. Хотя в широком смысле разве "полноразмерная картинка для данной превьюшки" не является тоже своего рода отношением между документом и ссылкой?..

Впрочем, это все философские вопросы, о которых можно долго спорить и холиворить. А возражений по существу на аргументы про <a name="..."> и <area href="..."> я так и не увидел...

Edited May 10, 2009 by SelenIT